Sender: boose@unixserv.rz.fh-hannover.de
Received: from deneb.dfn.de by dub-img-1.compuserve.com (8.6.9/5.941228sam)
        id GAA07567; Mon, 16 Jan 1995 06:49:15 -0500
Received: from unixserv.rz.fh-hannover.de (rzgw.rz.fh-hannover.de) by
deneb.dfn.de (4.1/SMI-4.2)
        id AA01063; Mon, 16 Jan 95 12:47:15 +0100
Received: by unixserv.rz.fh-hannover.de (AIX 3.2/UCB 5.64/4.03)
          id AA22748; Mon, 16 Jan 1995 12:47:36 +0100
Date: Mon, 16 Jan 1995 12:47:36 +0100 (NFT)
From: Andreas Boose <boose@unixserv.rz.fh-hannover.de>
Subject: VC/RC
To: 100112.220@compuserve.com
In-Reply-To: <941124202434_100112.220_BHA82-3@CompuServe.COM>
Message-Id: <Pine.3.89.9501161230.B31952-0100000@unixserv.rz.fh-hannover.de>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hallo Wolfgang!

Wir diskutieren schon die ganze Zeit in einer lokalen deutschen Gruppe
ber den VIC und dessen VC/RC. Es ist wirklich interessant, kannst Du sie
nicht lesen? Im folgenden Artikel hat Christian (er programmiert einen
C64-Emu auf dem Amiga, der jetzt verbessert wird.) mal einen kleinen
Zwischenstand ber den VC/RC zusammengefat, mit dem wir jetzt schon ALLES
$d011-mige, was auf allen 64'ern luft, erklren knnen.

Es sind aber noch nicht die endgltigen Definitionen, da mu noch dran
gefeilt werden, aber Du sollstest schon mal so einen berblick bekommen,
wie der VC/RC implementiert werden sollte, damit alle Tricks
funktionieren. Erfreulicher Weise ist Christian auch zu dem Schlu
gekommen, da es 2 VCs gibt. :-)

Wenn von X-Koordinate die Rede ist, so ist das die Sprite X Koordinate,
die 24 Pixel vor der linken Rahmengrenze liegt.

Und was habe ich gehrt, Compuserve soll billiger werden?

MfG Andreas


Empfaenger : /Z-NETZ/RECHNER/C64+C128/HARDWARE
Absender   : Cebix@NG-BOX.WWB.SUB.DE  (Christian Bauer)
Betreff    : Re: VIC-Interna
Datum      : Do 12.01.95, 19:16  (erhalten: 15.01.95)
Groesse    : 7894 Bytes
----------------------------------------------------------------------
A.BOOSE@LDB.han.de (Andreas Boose) schrieb am 10.01.1995
zum Thema "Re: VIC-Interna" folgendes:

AB> Hast Du Dir denn schonmal Gedanken gemacht, wo die Zeile mit den @@@@@
AB> abgeblieben ist? ;-)

Das ist einfach. In Zeile $33 machst du den #$19->$d011 vor X-Koord. 0,
also wird das Display eingeschaltet ($d011 steht noch auf #$1b von
Zeile 255, also Bad Line Condition), aber der RC wird nicht auf Null
gesetzt und es werden keine neuen Zeichenzeiger geholt, also stellt er
die 7.Pixelzeile der letzten Bildschirmzeile dar (man sieht sie ja auch
noch oben als Leerzeile, wenn man vorher ein POKE16383,255 macht) und
bei X-Koord. $160 wird das Display wieder abgeschaltet, da der RC auf 7
steht (warum der VC um 40 erhht wird, siehe unten).

AB> [Cebix' VC-Schrott gelscht]
AB> Wie willst Du das mit einem sich stetig erhhenden VC erklren?

Gar nicht (beim Bitmap-Modus wrde das sowieso total fehlschlagen).
Ging mir ja auch weniger um den VC, als um die Tatsache, da VC und
40-Zeichen-Puffer-Adressierung getrennt sind und nicht irgendwie
durch (VC MOD 40) gewonnen wird. Aber das ist ja evident.

AB> Ich habe fr sowas mal ein Testprogramm geschrieben [...]
AB> Der VC liest also zwei mal ab $0400, der FLI Effekt. Erklr' das mal mit
AB> einem VC, der auch noch synchron zum "Zhler im internen 40-Byte-
AB> Zeichenpuffer" erhht wird. :-)

Hier ist meine neue, zusammengefate RC- und VC-Definition (tataaa! :-):

1. Eine "Bad Line Condition" ist, wenn RASTER >= 48 und RASTER < 248
   und die unteren drei Bits...etc... (wie gehabt).

2. Tritt eine Bad Line Condition ein, egal wann, wird das Display
   eingeschaltet. Dies kann auch mitten in einer Zeile geschehen.
   "Display ein" heit bei mir, da er innerhalb der Textspalte nicht
   $3fff darstellt, sondern Textzeichen oder Bitmap.

3. Der VC lt sich nicht widerspruchsfrei durch ein einziges
   Register beschreiben, es mssen zwei sein. Ich nenne sie hier
   mal VCBASE und VCCOUNT, die beide 10 Bit breit sind. VCBASE ist
   ein einfaches Datenregister, VCCOUNT hat zustzlich einen Zhleingang.
   Das "VC", das auf den Adrebus gelegt wird, ist immer VCCOUNT.

4. Der RC ist ein einfacher 3-Bit-Zhler mit Reset. Er entspricht
   direkt dem "RC" auf dem Adrebus.

5. Beim VBlank wird VCBASE auf Null gesetzt, RC bleibt unverndert.

6. Bei Takt 0 jeder Zeile wird VCBASE->VCCOUNT gemacht.

7. Liegt bei Takt 0 eine Bad Line Condition vor, wird der
   RC auf Null gesetzt.

8. Das Lesen der Zeichenzeiger (Videomatrix-Zugriff) wird gestartet,
   wenn eine Bad Line Condition vorliegt und der Takt zwischen
   0 und 39 liegt. Es wird bei Takt 40 gestoppt.

9. Ist das Display an, wird in der Textspalte auf den Grafikspeicher
   zugegriffen (mit VCCOUNT in der Adresse) und nach jedem Zugriff
   VCCOUNT um eins erhht (dies gilt sowohl fr Text als auch Bitmap).
   Ist das Lesen der Zeichenzeiger aktiv, werden auch die Daten aus
   der Videomatrix (und dem Farbram) in den 40-Zeichen-Puffer gelesen.
   Das VCCOUNT-Erhhen ist aber an den Grafikzugriff gekoppelt.

10. Bei Takt 44 wird geprft, ob der RC = 7 ist. Wenn ja wird das
    Display ausgeschaltet und VCCOUNT->VCBASE gemacht. Danach wird geprft,
    ob das Display eingeschaltet ist. Wenn ja, wird der RC um eins erhht.
    Hinweis: Liegt eine Bad Line Condition vor, ist das Display _immer_
    eingeschaltet. Der RC wird dann auch noch erhht, wenn er auf 7 steht.
    Es sei auch darauf hingewiesen, da man durch diesen Mechanismus
    keine "ADD 40"-Hardware beim VC braucht.

Puh! Wenn ich nichts bersehen habe und alles so beschrieben ist, wie
ich es meine, sollte das die endgltige RC- und VC-Definition sein.
Zumindest kann ich _alle_ Effekte, die deine beiden D011-Test-Programme
hervorbringen, damit erklren (auer den drei $ff und den wilden
Verknpfungen natrlich), auch wenn man bei beiden Programmen den
Bitmap-Modus einschaltet (dann sieht man sowieso viel besser, was abgeht,
da der VC in jeder Zeile bentigt wird) und wenn man aus dem
dekrementiellen einen inkrementiellen D011-Effekt macht.

Die beschriebenen Algorithmen sind mit ein paar Zhlern, Komparatoren
und Flipflops leicht in Hardware umzusetzen.

Interessant ist auch, da es in beiden Programmen genau eine Stellung
gibt, in der die erste Bad Line Condition gar nicht eintritt, wenn
nmlich das #$18->$d011 genau dann erfolgt, wenn $d012 gerade auf #$39
gesprungen ist (oder unmittelbar davor steht, sich zu erhhen? Kommt
darauf an, wann das STA wirksam wird und wann die Bad Line Condition
geprft wird). In den Stellungen unmittelbar davor und danach ist
eine Bad Line da, weil entweder $d012 noch #$38 oder schon #$39 ist.
Dies ist ein Hinweis darauf (nicht der einzige), da das "Bad Line->
Display On" bei der positiven Flanke von Phi0 geschieht, aber nagel
mich nicht darauf fest.

AB> [CPU-Zyklenzhler]
AB> Was ist, wenn die Befehle unterschliedlich lange dauern? (Pagegrenzen)

Der Pagegrenzen-Extrazyklus wird nicht bercksichtigt (man kanns ja
auch bertreiben :-) Das wird erst wirklich wichtig, wenn man VIC und CPU
zyklenweise emuliert). Aber der Bcc-Extrazyklus ist drin.

AB> [PHI0, BA, S/LUM-Diagramm]
AB> Ich knnte ja auch einen Fototransistor an der Bildrhre
AB> befestigen [...]

Bei mir wars ein Zweikanal-Oszilloskop. :-)
Beim Fototransistor werden dieselben Koordinaten herauskommen, wegen der
Lightpen-Geschichte.

AB> Will sagen, S/LUM und Fernsehbild sind doch schon lngst Vergangenheit fr
AB> die Gegenwart des Busses. Fr die Tabelle, der das Timing des Bussystems
AB> zu Grunde liegt, ist es doch vllig uninteressant, wieviel Stunden es
AB> braucht, bis das Signal 'Textanfang' endlich mal am S/LUM Ausgang
AB> erscheint.

Doch, es ist interessant. Erstens kann man darber und ber die Sprite-
Koordinaten ermitteln, was der VIC an welcher _X_-Koordinate macht (man
kann dann auch z.B. bei deinem D011TEST.PRG die Zyklen des DEC D020 am
Bildschirm auszhlen und nur dadurch konnte ich ermitteln, wie RC und VC
funktionieren (dabei hab ich auch schon festgestellt, da Markos Diagramm
in diesem Punkt falsch ist)). Zweitens hat Marko es herausgefordert, indem
er in seinem Diagramm beides eingezeichnet hat, aber anscheinend nicht
ganz richtig.

AB> [Raster-IRQ-Komparator]
AB> Vergleicht er denn $D012 fr den IRQ? Das wird so angenommen, aber wissen
AB> tut es keiner. :-)

Was denn sonst? :-)

AB> ["The Making of $DE00"]
AB> Ich wute, wie man die RAM Adressen 0 und 1 lesen kann - mit dem
AB> Spritekollisionstrick auf dem Hiresschirm. Wir haben dann darber
AB> nachgedacht, wieso die beiden Bytes berhaupt auf dem Hiresschirm flimmern
AB> - und manchmal wieder nicht.

0 und 1 vom Prozessor aus lesen? Um das Flimmern zu sehen, reicht
doch schon ein POKE53272,4. Was fr ein Spritekollisionstrick?

AB> [RMW-Befehle machen zwei Schreibzugriffe]

Hab mir jetzt auch mal das 64doc besorgt. Komisch, da erst die
CMOS-Versionen zwei Lesezugriffe machen. Erinnert mich etwas an den
68000, der bei einem "clr" erst mal aus der Adresse gelesen hat,
bevor er die Null hineingeschrieben hat. Was ist das berhaupt fr
ein komisches Design beim VIC und 6502, das in _jedem_ Zyklus auf
Biegen und Brechen hinaus unbedingt zugreifen mu, selbst wenn es
total unntig ist?

Noch was: Ich hab mir mal das D011TEST.PRG nher angesehen. Ich finde
es stellenweise etwas konfus, mit den BCSs und RORs. Was fr eine Methode
verwendest du da, um den 6510 zyklengenau zu synchronisieren? Ich dachte
immer, sowas macht man mit dem Lightpen-Interrupt!?!

MfG,
Christian

-- TicroDom 1.10
  / Christian Bauer, Langenaustr. 65, 56070 Koblenz, Germany
\/ EMail: <cebix@ng-box.wwb.sub.de> or <cbauer@mzdmza.zdv.uni-mainz.de>

